Talk:Pikpik Carrot Pikmin/@comment-12360859-20160126055541
If they were added in Battle Mode and not Challenge mode, my theory would be extremely sound, but for now its just an educated guess. If it were in Battle Mode, my theory would be that because red and blue pikmin are reduced to a "basic pikmin" with no special traits, there would probably be a code that reassigns the values that represent their skills to the "basic" number. For example, Reds have a higher attack value than others, so they have to be set to the number that "normal" pikmin (Blues, Yelows, etc.) use and the same must be for speed and other things like that. So if yellows or purples or whites were added and they had "basic" attributes, this would confirm the "basic code" part of my theory. If that were true, it would mean that the code would be applied to the PikPik carrots (no matter what it's pretty obvious that PikPik Carrots are modified pikmin, for the reasons stated in the article), would allow them to walk and move; this would mean that they did not move in the Piklopedia simply because their speed value was set to the lowest possible, and was set to "normal" by the battle code. Using this logic, you can piece together the rest of my theory. There are just a few things I'm not sure about. Mainly, their voice. In the Piklopedia, they make no noise, so it is possible that there is a "voice value" that can set to a value that determines what voice they would use. The default would be the normal pikmin voice while only the bulbmin and carrots would have different values, the bulbmins' value would be for there voice while the carros' "voice" would be nothing. Maybe the "basic code" would set the voice value to "normal." This could be tested by having the captains in Battlemode start with bulbmin and see if they use the normal pikmin voice instead of the bulbmin voice. Another thing that confuses me: their attack. If the "basic code" gives them a regular attack why do the carrots not atack enemies? This is a pretty easy one which I am 90% sure abount, unlike the voice part. The developers took as many shortcuts as possible when adding the carrots, making them unable to move and turning off the voices, but reducing their damage to 0 would still have them latch on to enemies, they just wouldn't do damage. It is most likely that the developers completely recoded the carrots' "attack section," having them bounce off enemies. As a result, there are no values to change when applying the battle code. Finally, the last thing that bothers me: in the Piklopedia, the carrots aoutomatically plant themselves when they touch the ground. I have a fairly good solution to this, but I'm not super sure about it. It is likely that a certain section of the carrots' code was recoded for this as well, so this could not just be given new values and would have to be bypassed completely. This brings me to the second major point of my theory (the first was the concept of the "basic code")—why how the battle code even works on the carrots, as it would require certan parts of the code (mainly the self-planting part) to be bypassed. This brings me to my final point, which will take out two final problems with one stone. The first and main problem is how the planting code is bypassed, and the second is the fact that the glitch was discovered in Challenge Mode, not Battle Mode. My theory on how the planting code is bypassed is hard to directly prove, but will go into detail on how to find indirect proof that would greatly support it. It likely has something to do with the fact that the only know way to acitvate the glitch if to change the type of pre-plucked and in a standing position pikmin the captains start with. Let's backtrack for a moment and build upon the theory regarding the recoding of certain parts of the carrots' code. Here is some thing that is testable (get ready for a double colon): The carrots have two known areas recoded: the bouncing proccess in the attack area and a self-planting proccess that likely lies in the area related to standard actions behaviour. What if the the new code in each area did not replace the preexisting base code that all pikmin have, but simply precedes it and does not allow a way to continue to the rest of the code with out outside interaction? It's probably impossible to test this theory with the bouncing process, as there would likely be no "out" that would let you to bypass it to reach the rest of the attack code, however, the planting process would be easy to test. If you were able to plant a PikPik Carrot in game and spawn a controllable captain in the same area, you would just have to walk up to it and try to pluck it (I can think of two ways to do this: Spawn a captian in the Piklopedia, where carrots can be planted easily, or perform the glitch in a challenge level that has swooping snitchbugs, although they might not be able to grab the carrotmin). If it were to be plucked like a pikmin (probably with no animation) it would mean that there was at least some code left over, if nothing happened, it wouldn't didprove it, but the only other way to find out would be to go into the code itself. If the carrot functioned like a pikmin after being plucked, that would finish this and I could stop writing right now (actually it would just lend credibility to one possibility I came up with but not prove it), but that's impossible to know, so we'll just leave that alone for now. What I can say is my prediction on whether or not the carrot would be pluckable. And my prediction is... I don't know. If the programmers did not delete the base code and only had the new processess precede it, there would be no reason to delete just one part—the carrots can only be used in the Piklopedia anyways! However, someone with some foresight (more like paranoia) may have removed the plucking process, just in case. SO there's no way to know for sure without trying it. Anyways, back to before we backtracked (remember that?!). All that really matters is whether or not the self-planting code replaced or preceded the rest of the action code. It should be obvious that spawning the carrots in plucked state messes with the self planting code in some way. If in the earlier test it were proven that they could be plucked it would imply that the spawned in pikmin count as pre-plucked, meaning that the planting code would have been bypassed already. Another is that it simply comes from the fact that they are in a standing position causing a hitch in the code. Hold on, we're about to go on another tangent. When throwing a PikPik Carrot in the Piklopedia, you do not take from a pool of prespawned carrots, you spawn one in. Since carrots have similar code to pikmin, it can be assumed they have multiple "positions." What I mean by this is that a pikmin in the "standing" position is idle. A pikmin that is mid throw (has been thrown by the captain but has not reached target) is in the "throwing" position. A pikmin that is attacking is in the "attacking" position. When you spawn in a carrot in the direction you were looking. The question is, do you really "throw" the carrot, or do you fling a "standing" model. I would say that you throw it, as when it hits an enemy, it "bounces" off of it, which replaces the attack proccess, WHICH can only be started from a throw or command (c-stick). This means that the self-planting process is meant to be started from a throw. In truth, if it turned out you really did just fling a standing carrot, it wouldn't matter, it would just wouldn't help the theory. Anyways, we have deduced that it is likely that the planting process is likely to have been made to start from a "throwing" position. Spawning the carrots in a "standing" position would befuddle the process, causing it to proceed to the next one, which, unless it was removed, would be the rest of the standard action script. This is the basis for my theory on why the carrots become pikmin when hacked in. Wrapping up, I will adress the second problem and how this ties in to the battle code. Now, it is likely that many values that the developers assumed would never be used were left empty, so wouldn't the pikmin just sit there or crash the whole game? My explanation for that earlier was that in Battle Mode those values would be reassigned by the "battle code" meant to remove the strengths and weaknesses of the different pikmin. However, this glitch can be activated in Challenge mode, so why would that apply? I have one major theory with two variations (The first one will sound far-fetched, and it is; I'm just trying to give the battle code theory one last chance before it's thrown out). It is possible that there is a code used as a fail-safe meant to prevent pikmin from glitching out and/or crashing the game. This "fail-safe code" (very original name) would fill in values in te pikmins' code if they were missing or nonsensical, preventing disaster and allowing them to function as "basic" pikmin, although they would not have special abilities. Sound familiar? It is possible that the battle code ''is ''the fail-safe code, and is not actually tied to Battle Mode, but to the Pikmin Class itself (the template used for the base of the different Pikmin), but the only time it is programmed to forcibly reassign values is during Battle Mode, to even the playing field. Outside of that, it will only activate when needed, such as when SOMEBODY screws with the game and forces carrots to stand up. A "battle-code" that overrides values and removes strengths and weaknesses of pikmin to make them equal—plausible. A "fail-safe" code that fills in missing values to keep the game going—plausible. But having both processes being the same thing? Very VERY implausible. So this brings me to the more likely variation of the Challenge Mode theory: There is a failsafe-code, but it isn't the battle code. It just fills in basic values if the originals are unusable or missing. It's prett much the same thing I said before, just without the battle code's flaws weighing it down. One thing that could support this is that the carrotmin share there "idle leafe color" with bulbmin, both being green, which could be a result of a fail-safe value being filled in, but that's about it. In all truthfulness, it's probably more likely that the developers filled in some random or default values instead of writing a whole fail-safe process, but like I said, this part of the theory is more speculation and is not the main part. Uhh... I've been working on this for two hours and it's ten minutes to midnight and this thing is way too long to spellch, so... I don't know how to end essays. I mainly just wrote this because I knew I would forget soon and I would never post it if I didn't now, so I guess I be back to elaborate on whatever I haven't already when someone finds this in the future and comments that it's confusing. Goodbye.